home *** CD-ROM | disk | FTP | other *** search
- Path: dscomsa.desy.de!x4u2!mernst
- From: mernst@x4u2.desy.de (Matthias Ernst)
- Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
- Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
- Followup-To: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
- Date: 28 Mar 1996 12:00:25 GMT
- Organization: DESY
- Message-ID: <4jdv0p$lnr@dscomsa.desy.de>
- References: <4irn11$7ln@mimas.brunel.ac.uk> <Pine.Sola.3.91.960322041345.17711C-100000@ux5.cso.uiuc.edu> <4j03p4$fbt@hoho.quake.net> <Doq3sv.MzA@research.att.com> <4jcf89$2k9@crc-news.doc.ca>
- NNTP-Posting-Host: x4u2.desy.de
- X-Newsreader: TIN [version 1.2 PL2]
-
- Slobodan Celenkovic (Celenkovic.Bob@ic.gc.ca) wrote:
- : So the termination semantics is for cleaning-up just before process
- : termination? Of course, that is quite valid viewpoint. However I am still
- : not convinced that the resumption semantics is not valid.
-
- : Forgive my ignorance, for I did not read the book, but how is the
- : following typical example handled: say reading a file with many read
- : statements. Classical approach is check errno after each read statement.
- : It seems to me that the resumption semantics is much better, since it
- : covers all the code and concetrates error handling code into one place,
- : at the end. Hence no need for repeated checking of errno. Another nice
- : ting about resumption semantics is that it allows selective error
- : handling at different levels using clear code. At each level the error
- : handlers catch only the errors which it can handle, leaving others for
- : the higher levels. Only at the top, application level the termination
- : semantics is used because the error condition cannot be corrected.
-
- : Indeed it seems to me that both semantics are neeeded and complement
- : each other very well. I have no big projects to cite as examples, but my
- : personal limited expirience with smaller programs.
-
- : So why is the resumption semantics not needed? Of course it can always
- : be replaced by explicit error checking, but exceptions seem much
- : nicer/cleaner way of catching errors and many error conditions can be
- : handled. Maybe it all boils down to the style preference, explicit error
- : checking vs. resumption exceptions? In any case, why not give programmers
- : the choice?
-
- : Slobodan Celenkovic
-
- : P.S.: I used exceptions in Delphi's Pascal language which uses resumption
- : semantics until an exception reaches the top level where it causes
- : termination. I use exceptions for "normal" errors, like errItemNotFound
- : when searching in a table,...
-
- I fear you are confusing something here. What you [seem to (sorry if I get
- you wrong)] understand by Resumption is: 'an exception not handled in an
- invocation frame is automatically passed to the next outer frame.'
-
- This is not what is discussed in this thread.
-
- The idea of resumption or retry is that after an inner frame throws an
- exception the outer handler may alter the state or supply more information
- and then _REENTER_ the inner frame either at the point where the exception
- was thrown (resumption) or at the beginning of the try block (retry).
-
- The most used termination model means that after the exception is passed to
- the handler the inner invocation is no more existant, we can either
- explicitely try again (in a loop) or continue.
-
- Again, if I misunderstood you, take this article as obsolete.
-
- -- Matthias
-
-
-